Subject: Control Flows over RTP Option

From: [email-masked] (Matthew Finlayson)
Date: Thu, 21 Jul 94 16:38:56 BST

Marcia,

The HPR chapter of the new APPN Tutorial (GG24-3669-02 - dated April 1994)
discusses an optional tower on top of the Transport Tower, called the "Control
Flows over RTP Option" and described as follows:

>
> A node that implements the HPR control flows over RTP option, in addition
> to the HPR transport option, will support the use of:
>
> - RTP connections for CP-CP sessions
>
> - RTP connections for route setup requests and responses
>
> Only when both HPR nodes, conected by one or more HPR links, support the
> control flows over RTP option, will RTP connections and network layer
> packets be used to transport the CP-CP sessions flows and route setup
> requests and responses; otherwise, FID2 routing will be used.
>

Assuming that the Tutorial is accurate, (ie. you plan to present this new
option to the AIW in the new release of the HPR specification), we are
not clear on the rationale for making CP-CP sessions over RTP connections
part of this tower.

Our view of the reasons for making long-lived RTP connections a separate
option is as follows.

(1)  Long-lived RTP connections cannot take advantage of path-switch
     (since they are tied to a particular link).

(2)  They are potentially a significant resource overhead (one RTP context
     is required per HPR capable link).

(3)  They add significant implementation complexity.

(4)  An HPR capable node must support sending and receiving route-setup
     messages in FID2s anyway (to allow interoperability with base-level HPR
     capable nodes).

(Indeed the above list makes a compelling argument for obsoleting long-lived
RTP connections, not just making them optional!)

On the other hand if we look at CP-CP sessions over RTP.

(1)  CP-CP sessions over RTP will benefit significantly from the ability to
     path-switch (without going through the normal logic to re-establish
     CP-CP sessions).  This avoids pending LOCATEs being failed, resources
     needing to be re-registered, etc.

(2)  Since only a maximum of two RTP connections will be started between
     adjacent nodes (and possbily only one) there will not be nearly as
     significant a resource overhead.

(3)  CP-CP sessions over RTP are fairly straight-forward to implement.

It seems a shame to prevent implementations which do not implement
long-lived RTP from taking advantage of the benefits in (1).

For the above reasons we strongly recommend that CP-CP sessions over RTP are
kept part of the transport tower.

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================